Reliable data transmissions are accomplished by a combination of an acknowledgement (ACK) mechanism and retransmission. If any part of the data is not received, the transmitter needs to be made aware of it. The receiver sends acknowledgements to the transmitter for the data received. The transmitter retransmits the data till it gets an acknowledgement from receiver that it has received it. There are two types of retransmissions in practice. In traditional types, like Transmission Control Protocol (TCP), the transmitter determines data is lost if it does not receive acknowledgement within a configured time period. It pro-actively retransmits the data when this timer expires. In the newer types, like eXpress Transfer Protocol (XTP), the transmitter requests an acknowledgement instead of sending the data. When the acknowledgement packet arrives at the transmitter without the acknowledgement for any piece of data it had sent, the transmitter retransmits the data.
In the world of multicast, typically a negative acknowledgement (NACK) is used, as the number of receivers is very high. In such scenarios, positive acknowledgements would create an even bigger load of acknowledgement handling. The problem is mitigated in some protocols by using a hierarchy of receivers that collect, collate and transmit the acknowledgements.
There is a round trip delay from the time a data is transmitted and the corresponding acknowledgement is received. To better utilize the data channel, a transmission window is utilized. This is the amount of data the transmitter can transmit without waiting for an acknowledgement. This speeds up the data transfer. Problem happens when some segments from this window are lost in transit. In protocols like TCP, the transmitter retransmits everything from the first point of loss. This results in repeated transmission even for the data already received. This improved with the implementation of selective acknowledgement (SACK) as defined by RFC2018 and RFC2883 became more prevalent. RFC1072 defined the first version of SACK for TCP that was never implemented. Protocols like XTP have selective acknowledgement implemented from the beginning. With selective acknowledgement implementations, the transmitter retransmits only those portions that are not acknowledged. In all the current acknowledgement mechanisms, actual sequence numbers are used in reporting received spans. For a received data segment, the starting sequence number and the ending sequence number of the span are reported.
With the prevalent mechanism of selective acknowledgement, there are transmission problems and inefficiencies:                1. Transmission Window behavior not specified: RFC2018 does not adequately specify the transmission window behavior in conjunction with SACK. Some of the implementations allow the server to keep on sending window size minus the amount of data lost, updating it with all the SACKs received. The receiver process needs to hold on to all the data till the hole is repaired. This causes out of buffer situations at the receiver.        2. Data reneging at the receiver: RFC2018 allows for receivers to drop data, without informing, even if they are acknowledged in the SACK. This causes misunderstandings between the transmitter and receiver about what data the receiver actually has or does not have.        3. Effect of sack is meant to be cumulative. That means, each sack data needs to be evaluated in conjunction with prior received sack packets. If any sack packet is lost, the transmitter will end up misinterpreting the results.        4. RFC1072 introduced a concept of window scaling where they could address windows larger than 64K (64 times 1024) bytes window with span length field of two octets by introducing a scale factor. The problem with the scale factor was that there was loss of accuracy from the scaled number to the actual number. This required interpretation at the transmitter's end and also occasional duplicate transmission of data spans. This was overridden by RFC2018 specification.        5. All existing selective acknowledgements use the actual sequence number to indicate the data received. This is less than efficient as they consume more space in the control protocol or header. Protocols like TCP, that use header to transmit the acknowledgements, get limited by the number of spans they can report.        
Accordingly, there exists in the art a need for a system and method for reliable reporting of receiver window status.